Software obfuscation is a known technology for implementing software programs such that they are hard to reverse engineer. This technology typically includes the replacing of software functions with a sequence of table lookup operations and merging the function lookup with transform functions that make it substantially infeasible to discover the function and the function parameters. The resulting secured software program performs input and/or output operations that consist of transformed parameters. These transformed parameters may require specific adaptations in modules interfacing with the secured software program.
Data and software obfuscation techniques make use of transformation functions to obfuscate intermediate results. The concept of transformation functions differs from encryption, which is clarified in general with reference to FIG. 1.
Assume that there exists an input domain ID with a plurality of data elements in a non-transformed data space. An encryption function E using some key is defined that is configured to accept the data elements of input domain ID as an input to deliver a corresponding encrypted data element in an output domain OD. By applying a decryption function D using a key that corresponds to the key used by the encryption function E, the original data elements of input domain ID can be obtained by applying the decryption function D to the data elements of output domain OD. In a non-secure environment (typically referred to as “whitebox”), an adversary is assumed to know input and output data elements and have access to internals of encryption function E during execution. Unless extra precautions are taken in this environment, the key can be derived.
Additional security can be obtained in a non-secured environment by applying transformation functions to the input domain ID and output domain OD, i.e. the transformation functions are input- and output operations. Transformation function T1 maps data elements from the input domain ID to transformed data elements of transformed input domain ID′ of a transformed data space. Similarly, transformation function T2 maps data elements from the output domain OD to the transformed output domain OD′. Transformed encryption and decryption functions E′ and D′ can now be defined between ID′ and OD′. In case inverse transformations are to be performed, e.g. when results are to be communicated to the non-transformed space, T1 and T2 are injections.
Using transformation functions T1, T2, together with encryption techniques implies that, instead of inputting data elements of input domain ID to encryption function E to obtain encrypted data elements of output domain OD, transformed data elements of domain ID′ are input to transformed encryption function E′ by applying transformation function T1. Transformed encryption function E′ combines the inverse transformation function T1−1 and the transformation function T2 in the encryption operation to protect the confidential information, such as the key. Then transformed encrypted data elements of domain OD′ are obtained. Keys for encryption functions E or decryption function D cannot be retrieved when analyzing input data and output data in the transformed data space.
One of the transformation functions T1, T2 should be a non-trivial function. In case, T1 is a trivial function, the input domains ID and ID′ are typically the same domain. In case, T2 is a trivial function, the output domains are typically the same domain.
In general, secured software applications use transformed intermediate results which are unusable when intercepted. This property enables the protection of confidential data in secured software applications. In order to enable the secured software application to limit its functionality to a few (or one) particular devices, several technologies are known.
The transformation technology can be used to secure a wide range of software programs. FIG. 2 and FIG. 3 illustrate a known example of how a physical smart card used in a digital TV environment (see FIG. 2) can be replaced by a secured software implementation of the smart card functionality (see FIG. 3). It is to be understood that the present invention is not limited to the field of digital TV.
FIG. 2 schematically shows an example of a typical digital TV receiver 2a that receives encrypted digital TV content from a head-end 1 and outputs a signal to an output device 4 for displaying the digital TV content to an end-user. Arrows indicate a data flow in the direction as indicated. The head-end 1 transmits the digital TV content to a large number of receivers 2a. The receiver 2a uses an input module 21 to acquire the transmitted digital TV signal, which is subsequently provided to a content processing module 22a. The content processing module 22a is typically based on a general purpose processing unit 23a (e.g. using a 32 bit CPU) extended with a secured electronic circuit 24a to implement security functions such as encryption, decryption and secure key storage. Such processing may involve processing steps implemented in a detachably attached smart card 3. The result of the content processing is a signal suitable for rendering on the output device 4 such as a TV set.
The head-end 1, secured circuit 24a and smart card 3 are secured modules that are implemented such that it is difficult for an attacker to modify its intended operation. The input module 21, processing unit 23a, output device 4 and the interfaces between the modules are typically accessible to an attacker, so their proper operation cannot be relied upon.
FIG. 3 schematically shows an alternative example of a known digital TV receiver 2b that receives encrypted digital TV content from a head-end 1 and outputs a signal to an output device 4 for displaying the digital TV content to an end-user. Arrows indicate a data flow in the direction as indicated. The head-end 1 transmits the digital TV content to a large number of receivers 2b. The receiver 2b uses an input module 21 to acquire the transmitted digital TV signal, which is subsequently provided to a content processing module 22b. The content processing module 22b is typically based on a general purpose processing unit 23b (e.g. using a 32 bit CPU) extended with a secured electronic circuit 24b to implement security functions such as encryption, decryption and secure key storage.
Given the common availability of a secured circuit module 24b, the smart card 3 of FIG. 2 can be replaced by a secured software implementation running in the content processing module 22b. Hereto the processing unit 23b is configured with additional software for the functions that used to be implemented by the smart card.
As in the example of FIG. 2, the head-end 1 and secured circuit 24b are secured modules that are implemented such that it is difficult for an attacker to modify its intended operation. The input module 21, processing unit 23b, output device 4 and the interfaces between the modules are typically accessible to an attacker, so their proper operation cannot be relied upon. In order to secure the smart card functions in the to the attacker accessible environment of the processing unit 23b, the functions are implemented using secured software technology. The secured circuit 24b contains a memory for a set of secret keys that are used together with the output of the processing unit 23b to derive content keys for use in a descrambling circuit of the secured circuit 24b. One of the secret keys is installed during the manufacturing process. This so called Chip Secret Key is used to securely load other secret keys. A key loading message is embedded in the secured software and it is used to load a known secret key in the secure module. The secured software also has the fixed key encryption routine to encrypt a content key with the secret key that is stored in encrypted form in the key loading message. The fixed key encryption routine in the secured software application limits the application to execute on the device that can decrypt the key loading message associated with the secured software application.
The known technologies for enabling an obfuscated software application to be executed on a particular hardware device, also known as node locking, have in common that the output of a processing unit running obfuscated software is used by a secured circuit as an input to one or more security functions of the secured circuit. If the output of the processing unit is incorrect, then the secured circuit will not be able to perform the security function correctly. It is not prevented though that the software application itself can be executed. E.g. in the examples of FIG. 2 and FIG. 3 the output of the processing unit 23a, 23b is used by the secured circuit 24a, 24b as an input key enabling the decryption of the digital TV content or as a qualifier that the receiver 2a, 2b has knowledge about a (secret) key.
It is known that a software application running in a processing unit may poll predefined memory locations and use the resulting data in the further execution of the application. If the resulting data is incorrect then the software application will stop functioning correctly. The memory location is e.g. a specific hardware register containing e.g. unique values or cryptographic keys. The security provided by this polling method is limited, because the content of the memory locations may be modified.
It is known that a probing function implemented in a processing unit may e.g. activate a physically unclonable function (PUF) that produces a response result based on a challenge input provided to the function. PUFs are difficult to implement, because they have an initialisation problem. A further problem associated with PUFs is that a sender of a challenge input needs to know the possible response output of the PUF when triggered by the challenge input beforehand, because each PUF in each receiver is unique and produces an unpredictable response to a challenge. The PUF can only be characterised by a suitably large set of challenge-response pairs which may be obtained at manufacturing time or at a later stage in the deployment of the device by measuring responses to challenges.
There is a need for an improved technology for enabling the execution of a general purpose software application in a hardware device, while preventing the execution of the application or a binary copy of the application in another hardware device, without the above identified drawbacks of the prior art.